Software update generally includes a modification to, or addition/deletion of, one or more files of a software program. The software update can be performed to, for example, fix bugs of a particular version of the software program, to add or remove a functionality, to improve a property of the software program, etc. One method to carry out software update is carrying out incremental update. Using such a method, a software update provider device (e.g., a server) can compare between a particular version (to be updated) of application program files and a target version of the files, and generate one or more increment files that record difference information between the files. A device on which the software update is to be performed (e.g., a client device) can then download the increment files, merge the increment files with the corresponding files at the client device, to generate the target version of the files. The software update can then be completed by, for example, using the newly generated files for an installation process. With such an arrangement, there is no need to download the entirety of the target version of the files. As a result, less data traffic is produced, while the software update can be completed in a shorter time, thereby improving efficiency.
However, the efficiency of such a method can be affected by other factors. For example, for the same files of the same version of a software program, the content of such files can be different when distributed by different distribution channels. As an illustrative example, for an installation program of a UC Browser™ (http://www.ucweb.com/ucbrowser/), there may exist a file named “x” in a version 1.0 file of APK1a distributed by the GooglePlay™, while version 1.0 file of APK1b distributed by the Baidu™ mobile phone assistant does not include a file “x.” As another example, both version 1.0 files of APK1c and APK1a distributed by the UCWeb™ app store have file named “y,” but the file “y” in APK1c and the file “y” in APK1a may have different contents. In addition, the applicability of an increment file to a software program file can be specific to a distribution channel. For example, if it is intended to perform increment update on a version 1.0 file of the UC Browser to become a file of APK2 version 2.0, the installation process may require comparing APK2 with each of APK1a, APK1b and APK1c to obtain, respectfully, increment files CLa, CLb, and CLc. Therefore, to update a file, the existing increment upgrading method needs the generator of increment files (e.g., a server) to respectively compare a version of the file at various distribution channels with a target version of the corresponding file to be used for installation, in order to obtain the corresponding increment file.
Typically, there are many distribution channels for an application program, and an increment file associated with a distribution channel may not be reused for software updates associated with a different distribution channel. By requiring each software update process to include comparing different variants of program files (albeit associated with the same version) against the target version, the efficiency of the update process will be affected. Moreover, to store different sets of increment files associated with various distribution channels for various versions of a program file, a large amount of storage space is required.